---title: "Transcrição da Prova Teórica 1 — Mateus Silva Lopes" discente: "Mateus Silva Lopes" matricula: "20243004300" arquivo_scanner: "Mateus Silva Lopes_20243004300.pdf" prova: "Prova Teórica 1" semestre: "2026-2" data_aplicacao: "2026-10-19" status_presenca: "presente" total_paginas: 6 qualidade_leitura: legibilidade_global: "88%" classificacao: "Média Legibilidade (75-89%)" tipo_escrita: "Caneta esferográfica preta, cursiva arredondada e contínua" observacoes: "Texto fluído e compreensível contextualmente; uso de abreviações e cálculos manuais legíveis." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Mateus Silva Lopes ## Questão 1 — Projeto, Ciclo de Vida e Trade-offs (5,0 pts) — [Página 1] * **Legibilidade da Questão:** 91% ### 1.1 Projeto vs. Operação (Valor: 1,5) * **Resposta Manuscrita:** > "É um projeto, pois apresenta características do mesmo, como utilização de método ágil, possuir seu escopo bem definido e possuir tempo para executar (início + meio + fim)." * **Observações de Leitura (OCR):** Cursiva bem legível; destacou escopo e tempo (início + meio + fim). ### 1.2 Alternativas de Trade-off no Triângulo de Ferro (Valor: 2,0) * **Resposta Manuscrita:** > "Se o tempo foi impactado, existem duas alternativas, diminuir o escopo reduzindo a quantidade de funcionalidades, ou aumentar o custo para por exemplo aumentar a equipe e manter o escopo e o tempo." * **Observações de Leitura (OCR):** 100% legível; duas alternativas claramente delineadas (reduzir escopo ou aumentar custos para manter prazo). ### 1.3 Classificação do Ciclo de Vida (Valor: 1,5) * **Resposta Manuscrita:** > "O ciclo de vida de sprints de duas semanas é uma característica de metodologia ágil." * **Observações de Leitura (OCR):** Resposta concisa e legível. --- ## Questão 2 — Escopo, EAP e Backlog (5,0 pts) — [Página 2] * **Legibilidade da Questão:** 87% ### 2.1 EAP e Regra dos 100% (Valor: 1,5) * **Diagrama / Elemento Visual:** * Quadro pontilhado preenchido com lista e fluxo esquemático: * `# Professor Agente` * `1. Autenticação` * `2. Uso do LLM` * `3. Registro de conversas` * `4. Dashboard` * `5. Objetivos SMART` * Esquema lateral com bonecos: `Pergunta -> [trata a pergunta] -> Servidor / Responde`. * **Resposta Manuscrita:** > "Os 3 pacotes de trabalho são Front para interface, back para tratamento e conexão com LLM e banco, e banco para armazenar as conversas. EAP é hierarquica pois uma parte depende da outra." * **Observações de Leitura (OCR):** Desenhou representação mista de lista funcional e fluxo de mensagens em vez de árvore hierárquica estrita. ### 2.2 Detalhamento de Issues e Estimativa Relativa (Valor: 1,5) * **Resposta Manuscrita:** > * **Issue 1:** Titulo: "Interface do chat" | Descrição: "desenvolver a interface do chat com a entrada e saída." | Critério: "interface facilitada e acessível." | Estimativa: "usando (O + 4M + P)/6 para definir o tempo, O=1 semana, M=2 semanas, P=4 semanas, (1 + 8 + 4)/6 ≈ 2,16 semanas. A partir dessa issue deve-se testar se o back end está se comunicando bem com a interface." > * **Issue 2 / Justificativa Relativa:** [NÃO RESPONDEU / EM BRANCO] * **Observações de Leitura (OCR):** Aplicou a fórmula PERT tri-ponto para a estimativa da Issue 1; não apresentou a segunda issue comparativa. ### 2.3 Milestones vs. Sprints e Contexto do Kanban (Valor: 2,0) * **Resposta Manuscrita:** > "Milestone são mais completas que uma sprint, ou seja, carregam mais informações, uma milestone pode ter várias sprints, então nenhuma substitui a outra. Por outro lado deixar o Kanban puro sem sprints dificulta o processo de desenvolvimento pois além de existir issues que dependem de outras issues, permite que a equipe tenha muita liberdade de quando fazer, o que pode prejudicar a qualidade, pois se for usado as ultimas 3 aulas para um projeto de 15 aulas, claramente haverá problemas." * **Observações de Leitura (OCR):** Argumentação completa; escrita densa nas linhas finais. --- ## Questão 3 — Qualidade, CoQ e Definição de Pronto (5,0 pts) — [Página 3] * **Legibilidade da Questão:** 89% ### 3.1 Definição de Pronto (DoD) e Testes de Segurança (Valor: 1,5) * **Resposta Manuscrita:** > "A definição de pronto depende do contexto, o programa pode estar pronto e rodando no computador do dev mas quando ele envia para o git, ao realizar os testes no CI, ele falha e o CD não adiciona as alterações. Ou seja, ao omitir os testes de segurança, pode haver uma falsa premissa que o sistema está pronto. Por fim, a definição de pronto depende dos testes." * **Observações de Leitura (OCR):** Caligrafia nítida; boa distinção entre 'pronto localmente' e 'pronto integrado no CI/CD'. ### 3.2 Categorização de CoQ e Severidade (Valor: 1,5) * **Resposta Manuscrita:** > "a: custo de prevenção, b: avaliação, c: falha interna, d: falha externa. O maior custo neste caso é a falha externa, pois ela está prejudicando o usuário final, ela já parou de ser um risco, ela virou problema, e o pior deles neste caso, pois o chat ficou inviabilizado." * **Observações de Leitura (OCR):** Trocou as opções (c) e (d) na categorização, mas justificou acertadamente a gravidade da falha externa. ### 3.3 Heurística 1:10:100 e Limites em IA (Valor: 2,0) * **Resposta Manuscrita:** > "A regra diz que o custo é 100 encontrar um erro na produção, 1000 encontrar nos testes e 100 quando encontrada pelo cliente. Ou seja é muito mais barato corrigir o erro na base, do que nas pontas. Entretanto, não se pode tratar como lei universal, pois na matriz de problema x impacto, existem problemas de baixo impacto ou baixa probabilidade, que podem ser mitigados ou aceitos, sem a necessidade de diversos testes para remove-lo." * **Observações de Leitura (OCR):** Inverteu a escala numérica (escreveu 100, 1000 e 100), mas explicou com coerência o conceito de que é mais barato corrigir na base. --- ## Questão 4 — Riscos, Segurança de IA e Documentação (5,0 pts) — [Página 4] * **Legibilidade da Questão:** 90% ### 4.1 Risco vs. Problema e Matriz P×I (Valor: 1,5) * **Diagrama / Elemento Visual:** * Marcação `X` inserida no quadrante Crítico (superior direito, Probabilidade Alta × Impacto Alto). * **Resposta Manuscrita:** > "Esse evento foi um problema, pois ele já aconteceu, mas antes de ocorrer isso era risco. O problema de vazar a API da LLM, pode até encerrar um projeto, pois com ela não há barreiras, quem tem acesso pode esgotar todos os tokens em segundos, ou pior, gerar um gasto suficiente para quebrar a empresa." * **Observações de Leitura (OCR):** Posicionou o vazamento em Crítico; fundamentou no risco de esgotamento e quebra financeira. ### 4.2 Ações Imediatas e Ação Preventiva Permanente (Valor: 1,5) * **Resposta Manuscrita:** > "A primeira e mais urgente ação é cancelar essa chave e criar uma nova, depois avaliar o dano financeiro e por fim decidir se isso inviabiliza o projeto ou se o projeto ficará limitado. Mas para evitar isso é só botar de regra naquele arquivo que ele não será commitado." * **Observações de Leitura (OCR):** Mencionou revogação, avaliação financeira e regra de não-commit (.gitignore). ### 4.3 Modelagem de Risco de IA e Artefato ADR (Valor: 2,0) * **Resposta Manuscrita:** > "Prompt Injection, causa: uso de frases para burlar as diretrizes, impacto: alto, pode ferir a segurança do projeto, para evitar que isso aconteça, o texto enviado deve passar por verificação antes de ser enviado a LLM, sendo a probabilidade de prompt injection alta. Qualquer sistema que use LLM terá tentativas de prompt injection, onde o usuário poderia ter acesso ao código completo da questão. Tudo isso seria registrado no ADR." * **Observações de Leitura (OCR):** Modelagem completa com causa, impacto, probabilidade, sanitização prévia e indicação explícita de "ADR". --- ## Questão 5 — Comunicação, Stakeholders e Conflitos (5,0 pts) — [Páginas 5 e 6] * **Legibilidade da Questão:** 88% ### 5.1 Comunicação Síncrona vs. Assíncrona no GitLab (Valor: 1,5) — [Página 5] * **Resposta Manuscrita:** > "A comunicação síncrona é boa para discutir o andamento do projeto como a daily do SCRUM, mas péssima para decisões importantes do projeto, confiar apenas na memória da pessoa para lembrar tudo é arriscado. A assíncrona ela é mais rígida, não possibilitando esquecer ou fugir do escopo, mas ela é engessada, não possibilita resoluções rápidas. Utilizar um Kanban garante que o time tenha registro das issues, e que seja fácil rastrear o andamento de cada uma." * **Observações de Leitura (OCR):** Comparação clara com rituais (daily) e rastreabilidade via issues no Kanban. ### 5.2 Matriz Poder × Interesse e Estratégia de Comunicação (Valor: 1,5) — [Página 5] * **Diagrama / Elemento Visual:** * Quadrante *Manter satisfeito* (Alto Poder, Baixo Interesse): `4, 5` * Quadrante *Gerenciar de perto* (Alto Poder, Alto Interesse): `3` * Quadrante *Monitorar* (Baixo Poder, Baixo Interesse): `2` * Quadrante *Manter informado* (Baixo Poder, Alto Interesse): `1` * **Resposta Manuscrita:** > "Os alunos possuem o maior poder e interesse, pois são eles que vão desenvolver o programa, logo eles precisam de contato frequente, utilização de Kanban, e alto conteúdo. Por outro lado o professor tem baixo poder mas um interesse mais alto por ser o cliente." * **Observações de Leitura (OCR):** Aluno inverteu os papéis conceituais de Alunos (1) e Equipe (3), e considerou que o Professor (2) possui baixo poder por ser cliente. ### 5.3 Modos de Conflito de Thomas-Kilmann (Valor: 2,0) — [Página 6] * **Resposta Manuscrita:** > "Usaria mediação, tentando explicar o por quê, de maneira que pudesse talvez achar o meio termo. Não concederia, pois o risco de alucinação é real, sendo assim prejudicaria a qualidade, e nem usaria autoridade pois poderia afastar o cliente." * **Observações de Leitura (OCR):** Embora não tenha usado os termos técnicos exatos em inglês ou português clássico de Thomas-Kilmann, expressou perfeitamente as posturas de Conciliação/Compromisso ("meio termo"), Acomodação/Concessão ("não concederia") e Forçar/Poder ("nem usaria autoridade").